DRAFT — under teacher review.

Shoulders of Giants

The Hamilton and Alexandra College · Year 12 · 2026

"Identifies existing and possible solutions to inform design ideas."

Great designers rarely start from a blank screen. Before you sketch your first UI or write your first script, you study what's already out there — games and tools that solved a similar problem — and you let those solutions shape your thinking. This is C5-3 Step 1, and it's one of the fastest ways to lift the quality of your design work.

Why look at existing solutions?

Every game released on itch.io, every open-source Godot project on GitHub, every polished mobile app represents thousands of hours of design decisions — many of them hard-won. When you examine them carefully, you borrow the lessons without repeating the mistakes.

The study design asks you to identify existing solutions (things already built) and possible solutions (approaches that could work, even if no one has built exactly what you need yet). Both matter. A solution doesn't have to be popular to be useful — it just has to be relevant to the problem your SRS describes.

Note

Aim for at least 2–3 solutions. A mix of sources gives you stronger evidence: commercial games, open-source Godot projects, student examples, or competitor apps your client already uses.

What counts as an existing solution?

For a Godot game project, look at:

Published games — especially ones in your genre. Play them and take notes, not just screenshots.
Open-source Godot games — search GitHub for Godot projects similar to yours. You can read the actual code and scene structure.
itch.io game jams — a goldmine of small, focused games that solved one design problem well.
Game tools and engines — if your SRS mentions a specific mechanic (inventory, dialogue trees, tile maps), look at how existing Godot plugins or other engines approach it.
Partial matches — a game that shares only one relevant feature still counts. You don't need a perfect clone of your idea.

Tip

Possible solutions include approaches you haven't seen implemented yet — for example, "a card-based level select that doesn't exist in my genre but would suit my players." Identifying a possible solution and explaining why it fits your SRS is strong analytical thinking.

Analyse each solution in a table

Don't just list the games you looked at. Break each one down:

Solution	What it does well	What it does poorly	How it relates to my problem (SRS link)
Celeste (Maddy Makes Games)	Clear, readable level-select map; instant restart on death encourages retry	No in-game hint system for stuck players	My SRS requires a level-select screen and a low frustration loop — both addressed here
Open-source Godot platformer (GitHub: example/repo)	Clean scene structure; reusable state machine for player movement	No save system; UI is placeholder only	My SRS requires persistent progress — I can see what's missing and plan accordingly
Candy-match mobile game (competitor app client uses)	Card-grid layout scanned quickly by players; satisfying feedback sounds	Heavy monetisation interrupts flow	My SRS calls for a similar scan-friendly layout without ads

Note

Every cell must be your own analysis, not a copy of a review. If you can't say how the solution relates to your SRS, you haven't finished the analysis.

Connect findings to your design

The table is evidence. The connection is the argument. You must make the link explicit:

Worked example: After studying how Celeste's level-select map uses a simple node-and-path layout, and after looking at a card-grid layout in a mobile match game that my client already plays, I decided to use a card grid for my level-select screen. A grid lets players scan all available levels at once without scrolling — which suits my SRS requirement that players can jump back to any completed level in under two taps.

Notice the structure: "Because [existing solution] does [specific thing], I decided [specific design choice] because it addresses [SRS requirement]." That's the sentence pattern that gets you to Proficient and beyond.

Performance levels

Level	What it looks like
Basic	Names one solution with a brief description
Developing	Describes features of one or two solutions
Proficient	Identifies existing AND possible solutions and uses them to inform design ideas
Strong	Analyses multiple solutions with explicit links from specific findings to specific design choices

Quick checklist

2–3 solutions identified (mix of existing published games, open-source projects, or other relevant software)
Each solution analysed: strengths, weaknesses, and relevance to your SRS
At least one explicit "because X does Y, I decided Z" connection written out
Both existing products AND at least one possible alternative considered
Table cells contain your own analysis, in your own words — not copied from reviews

Check Your Understanding

Q1. Why does the study design ask you to identify "possible" solutions, not just popular ones?

...

Popular games are designed for large audiences with different needs from your client. A possible solution — even one that doesn't exist yet in your genre — might be a better conceptual fit for your SRS. Considering possible alternatives shows you're thinking about the design space, not just copying what's trending.

Q2. What's the difference between "I looked at 3 games" (Developing) and Strong-level evidence?

...

At Developing, you describe what the games do. At Strong level, you connect specific findings to specific design decisions: "Because Game X uses a card grid for level select, and my SRS requires players to resume quickly, I adopted a card grid." The explicit link — not the number of games — is what earns the higher band.

Q3. Name one good source of existing solutions for a Godot game project.

...

Good answers include: itch.io (searchable by genre and engine); GitHub (search "godot" + your mechanic, e.g. "godot inventory system"); open game jams; or commercial games in your genre that you can play and document. Open-source projects are especially useful because you can study the scene and script structure, not just the look.